Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) supports the ability to configure priorities (e.g., up to eight) for tunnels (e.g., Label Switched Paths, or “TE-LSPs”). Based on priority level, certain tunnels may be preempted by tunnels having a higher priority. That is, priorities may be used to give higher precedence to tunnels carrying higher priority traffic (e.g., sensitive/critical traffic), and lower precedence to tunnels carrying lower priority traffic (e.g., conventional data). (Note that tunnel priority need not be related to traffic priority, as will be understood by those skilled in the art.) Although preemption is a particularly useful mechanism in certain circumstances, it may lead to traffic disruption and network perturbation due to potentially massive rerouting of preempted tunnels (e.g., causing substantial control plane burden, traffic jitter, etc.).
One particularly non-disruptive solution is referred to as “soft preemption”, which provides a “make before break” preemption scheme such that preempted tunnels may be reestablished along new routes prior to being preempted from their old routes. As those skilled in the art will understand, while soft preemption is non-disruptive, it potentially causes temporary congestion within the network (e.g., since for a short period of time, two tunnels are in place: the newly admitted high priority tunnel and the preempted tunnel that has not been yet rerouted).
Although soft preemption reduces disruption of traffic (e.g., the forwarding plane), preemption of a large number of tunnels by the establishment of a higher priority tunnel (e.g., due to initial establishment or reoptimization/rerouting) may still cause network perturbations. Particularly, at the control plane burdens and traffic shifts that lead to traffic jitter may be problematic given a large number of displaced tunnels. For example (e.g., in networks where dynamic bandwidth resizing is used), a large high priority tunnel may be reoptimized along a (slightly) more optimal path, resulting in preemption of a very large number of lower priority tunnels.
Current network protocols (e.g., the Interior Gateway Protocol, IGP, with MPLS TE extensions) provide routing nodes (e.g., tunnel head-end nodes) with information relating to available bandwidth per priority level. A path computation algorithm executing on the routing node typically attempts to locate a shortest path for a tunnel having sufficient bandwidth for the priority level of the tunnel (e.g., a shortest constrained path, as in Constrained Shortest Path First, or “CSPF” computation). This computation is performed regardless of the number of tunnels potentially preempted along the newly computed path, particularly because such information is not generally available to the routing node. Thus, the routing node has no way of knowing that establishment of a tunnel along a path, whether for an initial set up of the tunnel or a reoptimization to a (slightly) more optimal path, would result in a large number of tunnels being preempted/displaced.